chore(attribution): drop the temporary settings enablement - #5430

PR body contract — issue linkage

This PR body conforms to the issue-linkage contract. Nothing to do.

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Claude finished @kyle-sexton's task in 1m 27s —— View job

Security review — no issues found

• Gather context (PR diff, changed files)
• Apply skip-gate check
• Review changed files for security-relevant issues
• Check instruction-surface deletions against protected classes
• Post findings / conclusion

Scope. The only change is in .claude/settings.json: it drops the "attribution@melodic-software": true key from enabledPlugins and adds "provenance@melodic-software": false in byte-sorted position. No other file changed.

Instruction-surface lens. enabledPlugins toggles are the kind of standing-config change this lane's deletion lens exists to catch, so I read it against the protected-class list in docs/conventions/instruction-exception-register/README.md (consulted — present in this checkout) rather than skipping on "it's just a config line":

• Removing the explicit true for attribution@melodic-software doesn't disable the plugin. Per scripts/check-plugin-catalog-enablement.sh's documented coverage rule, a catalogued plugin is covered when either the fleet list in standards enables it or this file carries an explicit key — and standards#654 (merged, per the PR body) now enables it in the fleet list. If that merge order were ever wrong, the same gate's "UNENABLED PLUGIN" check fails loudly in CI rather than silently dropping coverage, so a deterministic validator still enforces the property the deleted line used to. That takes it out of the register's finding criteria ("a rule that a mechanism still enforces is not a finding").
• "provenance@melodic-software": false is an explicit, recorded opt-out of a deprecated shim plugin — tightening, not loosening, and it's required for the same gate to pass (an uncovered catalog entry is the gate's other failure mode).

Other checks. No changes to permissions, hooks, env, or extraKnownMarketplaces; no secrets, tokens, or credential handling; no injection surface; no GitHub Actions workflow touched (this lane defers workflow-hardening findings to zizmor regardless).

No security findings to report.

Claude finished @kyle-sexton's task in 1m 25s —— View job

CI code review

• Gather context (diff, PR body, check-plugin-catalog-enablement.sh, catalog)
• Understand the request (/review:code-review lane)
• Review the diff
• Post results

Skip gate: this PR is a 2-line, mechanical .claude/settings.json edit — remove "attribution@melodic-software": true, add "provenance@melodic-software": false in byte-sorted position. No meaningful review surface beyond what's checked below, so no findings to report.

What I checked:

• Diff matches the PR description exactly (verified via git diff origin/main HEAD -- .claude/settings.json and gh pr diff).
• enabledPlugins keys stay in byte order after the edit (animation … playgrounds, provenance, retro-audio).
• .claude/settings.json parses as valid JSON (jq empty).
• Both attribution and provenance remain catalogued in .claude-plugin/marketplace.json (84 total catalogued plugins, matching the PR's claim), and both plugin directories still exist on disk — consistent with the PR's statement that the provenance shim removal is deferred to a later release.
• Read scripts/check-plugin-catalog-enablement.sh: an explicit false key does count as coverage for a catalogued-but-unenabled plugin, so the added "provenance@melodic-software": false is the correct way to satisfy that gate for a plugin not named by the fleet list.

Not independently verified (author-claimed): whether melodic-software/standards#654 actually flips attribution@melodic-software to true in the fleet list, and the PR's merge-order claim. This sandbox has no network access to fetch components/cloud-environment/fleet-plugins.json from the standards repo, so I could not run check-plugin-catalog-enablement.sh myself. If the fleet list does not yet enable attribution@melodic-software, the same script (wired into .github/workflows/ci.yml) will fail CI with an UNENABLED PLUGIN error on this PR's head — so this is self-guarding rather than a silent risk, but I'm flagging it as unverified by me rather than confirmed.

No findings.